Security administration can be costly and prone to errors as administrators usually specify access control for each user on a system, individually. With Role-based Access Control (RBAC), security is managed at a level that corresponds closely to an organization's structure. RBAC regulates access to computers or network resources based on roles of the users within the organization. In this context, access is the ability of a user to perform a specific task, such as view, create, or modify a file. Generally, roles are defined according to existing roles within an organization, such as job position, authority, or responsibility. Because it reduces the complexity and cost of security administration in organizations, RBAC continues to be a prominent model for access control.
Typically, in RBAC, users are assigned one or more roles, and each role is assigned one or more privileges or permissions that permit users to perform specific tasks. Therefore, to manage security in RBAC systems, users can perform only the functions associated with their roles. When properly implemented, RBAC enables users to carry out a wide range of authorized tasks by dynamically regulating their actions according to flexible functions, relationships, and constraints. In addition, in the RBAC environment, authorized users can easily create, change, or delete roles as the needs of the organization evolve, without having to individually update the privileges or authorizations for every user.
In RBAC systems, different administrative functions can be assigned to different roles, thereby distributing the administrative functions amongst a number of users. To allow this distribution to happen, most operating systems outline certain commands that allow some roles to perform administrative functions. These commands can be called privileged commands, as they allow certain authorized roles to perform privileged functions relating to system management and security administration, such as creating filesystems, rebooting the system, modifying roles and permissions, and so on. Some privileged commands can create certain objects, such as files, directories, and so on, and in RBAC, these dynamically-created objects typically have traditional access permissions (i.e., the object is owned, and access permissions governed, by the user that executed the privileged command, and not by the user's role). Access permissions are typically presented in a 10-bit format, where the first bit indicates the type of object, the next three bits indicate the permissions for the owner, the following three bits indicate permissions for the group, and the final three bits indicate permissions for other users. For example, the access permissions could be -rwxrw-r-, which indicates that the type of object is a file, the owner has read (r), write(w) and execute(x) permissions, group members have only read (r) and write (w) permissions (a ‘-’ represents absence of a permission), while others have only read (r) permissions.
Traditional access permissions are assigned according to the user, not the role, and therefore, unauthorized users can be allowed access to the objects. As a result, using traditional access permissions in the RBAC system can create a security gap, where, in certain situations, users could exploit the vulnerability of the RBAC system. For instance, if the traditional access permission of the created object is ‘-rwxr-xr-: user A: staff’ then the user A has read (r), write (w), and execute (x) permissions for the object, and the group ‘staff’ has read (r) and execute (x) permissions for the object, which in this case, is a file. In this case, an unauthorized user belonging to the group ‘staff’ can copy the entire object using any utility as the unauthorized user has read (r) and execute (x) permissions for the object. Here an unauthorized user can be a user that does not have the right authorization according to his role, to access the object. Therefore, the assignment of traditional access permissions in RBAC can lead to an information leak, which could raise security issues.
Typically, to overcome this potential security gap, users have to explicitly change the access permissions of the objects, to provide security for the objects. Since a user has to manually change the access permissions, errors can occur, or users may forget to change the default access permissions. Furthermore, in certain cases, the users may not set the right access permissions. In addition, as users change access permissions, there is no uniformity in the assigned access permissions, which can again lead to security breaches.